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METHOD AND SYSTEM FOR INTEGRATING FEEDBACK LOOPS IN MEDICAL 
KNOWLEDGE DEVELOPMENT AND HEALTHCARE MANAGEMENT 

Inventors: 
Stephen J. Brown 
Geoffrey J. Clapp 

CLAIM OF PRIORITY 

This application claims the priority of U.S. Provisional Application No. 60/461,105 filed 
April 7, 2003 and U.S. Provisional Application No. 60/461,526 filed April 8, 2003, both 
of which are incorporated herein by reference. 

E-health technologies are enabling a shift in the paradigm of healthcare from a model 
overly devoted to episodic, crisis-driven care toward a model characterized by continuity, 
crisis prevention, citizen empowerment, and ubiquitous monitoring and management of 
health and lifestyle factors outside of the traditional patient encounter. This paradigm 
shift is generating new opportunities and demands to advance and disseminate medical 
knowledge toward truly individualized care, yet new tools are needed before such 
advances can be integrated into clinical practice and be made available to citizens. The 
need for new tools is particularly acute - and the opportunity particularly large - in 
chroiiic care, where the need for care is increasing due to the aging population while the 
supply of caregivers is declining. 

This proposal research and develop of a comprehensive new methodology and tool set for 
medical knowledge management, dissemination,^ and individualization. Hie research and 
development activities mclude (1) development of an ontology and semantics engine for 
medical knowledge and patient iiifonnation from diverse and heterogeneous sources in 
order to determine best practices and consensus standards of care on a continuous basis, 
(2) development of decision support and knowledge dissemination tools in order to 
generate timely, relevant, and individualized care plans and patient education, and (3) 
development of a continuous feedback methodology and system whereby data gathered 
firom the citizen enables care providers to automatically individualize care plans and 
patient communications and medical researchers to continuously test and validate mles 
and associations that drive that individualization. 

Additionally, tools will be developed to enable researchers to identify patient 
characteristics that correlate to disease progression and outcomes and study of disease 
based on far more detailed patient data, collected at far higher frequency, and on a larger 
scale than was previously possible. The vast new amounts and sources of data, 
particularly hi^ frequency data from ubiquitous monitoring outside of the traditional 
encounter necessitates the development of a new generation of knowledge management 
tools that automate and integrate the collection, processing and dissemination of medical 
knowledge to a greater degree than has previously existed. 

As these e-health care management tools are disseminated and introduced into clinical 
practice and medical research, it will become possible for care providers, patients, and 
researchers to better imderstand, predict, prevent, and manage disease. The overall goal is 
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to apply and generate medical knowledge in a continuous dynamic feedback process that 
leads to the lowest achievable risk and cost to society and the highest quality of care and 
quaUty of life for citizens. 



II. Executive Summary 

In view of the above, MedKnowledgeMent aims to provide the methodology and tools 
for implementing a comprehensive knowledge management strategy in the medical 
environment, with the capability to encompass, classify, process and deUver the 
necessary information at the appropriate time. 



An overview of the Project 

Project Overview 




The proposed project will mclude- 

L Information and Knowledge sources- 

Relationships will be established with sources of medical knowledge, including 
Universities, Medical Schools, Hospitals, Clinical Laboratories, Primary Care Units, 
Physicians, Care Managers, Medical Research Facilities, medical Uterature, and other 
sources of medical knowledge. There shall be co-ordination with these sources in 
order to develop the overall system. 

K Knowledge Acquisition- Knowledge Base: 

An ontology will be developed for medical knowledge in order to specify how 
medical knowledge sources apply to specific disease conditions and patient 
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populations. In this ontology, each disease diagnosis will be associated with a set of 
representational terms covering aspects of care for the condition. Sub categorization 
under the aspect of care will include available treatments, and conditions upon which 
such treatments are used. Based on this ontology, a medical knowledge base will be 
developed from which it will be possible to search for and determine the consensus 
standards of care based on search criteria. An application program interface (API) and 
query language will be developed to this knowledge base so that other programs can 
use the knowledge base to run queries for specific needs in order to determine and 
derive consensus standards of care in a structured way that can be applied as a rule 
base a decision support system. For example, a care management program could seek 
information on the consensus standard of care for frequency of a particular lab test for 
a particular disease, as in HbAlc tests for a patient with Type n diabetes m a 
particular age group of patients. Because lab tests for particular diagnosis will be part 
of the ontology for classification of knowledge in relation to a disease, the 
methodology will allow such a query. Research and development needs to be done to 
create a generally applicable ontology and semantic network that will allow a scalable 
classification of knowledge across a wide range of disease conditions and 
populations. Interface to this subcomponent will be an API and query language. For 
this project, care plans will be developed for a range of conditions including Chronic 
Obstructive Pulmonary Disease, Congestive Heart Failure, Type II Diabetes Mellitus, 
End Stage Renal Disease/Transplant, and Depression. 

ni Information Acquisition- Information Base : 

An ontology and query language will be developed in order to extract data from 
existing clinical information systems including Electronic Health Records (EHR), 
Laboratory Databases, Medical Claims Databases, Genetic and Molecular Biology 
Databases in addition to patient self-reported data that is entered via the Mtemet and 
self-care devices. Based on this, an Information Base is generated and integrated in 
real-time. 

Semantics Engine will have the capability to integrate patient information firom 
multiple sources of External Data, including electronic health records, laboratory 
data, medical claims data, genetic and molecular biology data. Semantics Engine 
references the data available from the external sources, and integrates this data into 
the patient's Information Base through the use of an API. Data is classified in a 
standard manner to allow the extraction of necessary elements to compute risk factors 
for each of the health contexts in the 3-dimensional model of disease for every 
patient. 

The Electronic Health Records (EHR) of a patient is referenced, and information is 
extracted by the usage of Natural Language Processing Algorithms. The typical 
information that would be extracted from an EHR includes 

• Patient demographic variables, including name, age, sex, race, national ID 
number, contact information 

• main diagnosis, co-morbid conditions, 

• chief complaints, physicd examination findings, 
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• family history, 

• lifestyle related factors, such as a history of smoking , alcohol consumption, 
exercise 

• frequency of visits to the healthcare facility, 

• referrals to other health providers, including specialists, co-morbid conditions, 

• diagnostic tests ordered, dates of ordering of these tests, and results of the 
diagnostic tests. Included here are the radiological, nuclear medicine 
investigations and functional tests such as exercise stress tests. 

• prescribed medication, response to medication, development of side-efifects, 
especially if the side-effects have necessitated withdrawal of the medication, 

• history of admissions, special procedures (such as operations) undertaken, 
indications for the procedure 

Laboratory Data includes data from a diagnostic laboratory- biochemical, pathology, 
and microbiology, immunological investigations. The data which is of primary 
concem to the system is the date, and type of test, and the test result. The test results 
may be used to schedule additional tests through the use of further protocols. For 
example, if a test value is reported as higji, the Care Manager Program institutes an 
intervention, as indicated by the protocol, in addition to scheduling a follow up 
laboratory test to check the effectiveness of the protocol in patient care. 

Medical Claims Data from the database of an insurer or public health subsidizing 
organization is extracted by the Semantics Engine and complements the data in the 
EHR. Medical Claims Data provides information on the dates and nature of 
procedures, tests and consultations that a patient undergoes. This information is 
further processed by protocols. For instance, the claims data for a diabetic patient 
may show that the recent most visit to an ophthalmologist to be 3 years previously, 
whereas the standard of care requires this to be every 2 years. Care Management 
Engine alerts the care manager to this fact, and a new consultation is scheduled. 
Semantic Engine correlates the medical claims data and EHR in order to prevent 
duplication of data. 

Genetic and Molecular Diagnostics Database- Semantic Engine extracts a patient's 
genetic and molecular profile from a Genetics Database, and incorporates this 
information within Information Base. This is used by Care Management Engine to 
modify the treatment plan of an individual on the basis of his/her molecular and 
genetic profile. For example, patients with polymorphisms in genes for cytochrome 
oxidases exhibit a different degree of metabolism, and side effects of antidepressants 
and tests for cytochrome polymorphisms may be used to determine the best dmg to be 
used in a given patient. Ano^er interesting application is that this data may be used 
by the research engine to correlate subgroups of patients based on treatment response 
and disease outcomes (phenotypic variables) to genetic variations including SNP 
markers and molecular profiles. . Many chronic diseases such as diabetes, 
hypertension, cardiovascular disease, obesity, and mental health disorders are thought 
to have a genetic component. 
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lYi Information and Knowledge Processing: Decision Support Tools- 
Queries will be run on Information Base to correlate the extent to which provided 
care is consistent with the consensus standard of care- the Knowledge Base. Decision 
Support Tools (DSTs) will use the results of these queries to generate reports that 
identify potential gaps in patient care. These *gaps' m care, the difference between 
hitherto provided care and the consensus standard care' is summarized, and presented 
to caregivers, i.e. physicians and care managers. For example, patients with diabetes 
are required by knowledge base to have an HbAlc test every three months. In cases 
where DSTs detects that the last such test has been performed more than this interval, 
a recommendation is given to check if the patient has had an unreported test. If this is 
the case, then the missing test results are entered into the information base. If not, 
then the test is performed. In the interest of patient safety and quaUty assiirance, it is 
necessary that the physician or care manger screens the *care gap' report and 
confirms that the gaps are not due to missing data. 

Informatio n and Knowledge Rendering: Rendering Engine- 
Dialogues and health content is rendered for presentation, by a Rendering Engine that 
converts the data into a format which may be interpreted by different types of devices 
including Personal Computers cormected to the Internet, interactive Television, 
Personal Digital Assistants, and remote health appliances, such as the Health Buddy 
TM appliance that are used by a patient to communicate with the system. Conversely, 
Rendering Engine converts patient replies to dialogs, and biometric measurements 
from different devices into Uie standard system format. 

VL Information and Knowledge Acquisition: Feedback Engine- 
The Feedback Engine is of key importance in the knowledge management cycle. 
Feedback Engine will enable a regular and ongoing interaction between the patient 
and the care manager, physician and researcher, outside of the clinical encounter. 
Feedback Engine will interface with DSTs using Application Program Interfaces, to 
generate personalized recommended •care plans' based on the patient's updated 
Information Base and disease Knowledge Base. Care plans will be forward looking 
and will recommend steps for monitoring and managing patients along a future 
timeline. The structure of the monitoring and management plan is based on the 
characteristics- symptoms, behavior (i.e. treatment compliance), knowledge and test 
results matched to medically relevant aspects of care. The plan will mclude 
monitoring, management and follow-up directly with the patient and reporting to the 
care manager. This is an intervention that would be implemented using eHealth 
technologies for frequent dialogues with the patient over a network. It will also 
include a customized health education plan. Caregivers, i.e. physicians and care 
managers decide, in consultation with the patient the future course of action, with 
regard to the recommended care plan. In the first iteration of the patient monitoring 
and management plan, the plan is based on tiie personalization of a pre-packaged care 
plan designed for the specific medical condition of the patient. Subsequent iterations 
will allow for progressively greater customization and individualization of plans to 
the information base. Feedback Engine will allow the system to correlate and analyze 



5 



data within Information Base and Knowledge Base and apply these analyses to make 
new discoveries and further the growth of medical science. 



Feedback Engme will consist of three components- 



EXTERNALDATA 
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SYSTEM ARCHITECTURE 
System Architecture, from the viewpoint of Feedback Engine 

Dialopue Enpne- Dialogue Engine maintains ongoing patient interaction that is 
individualized to the patient. It sends dialogues (content) to the patient for display 
on the communication device. Dialogues include medical advice to the patient, 
educational materials, and queries to a patient regarding his/her medical 
condition. Dialogues can also be script progranas instructing the Biometric Device 
to collect physiological measurements of the patient. Dialogues are generated 
using Information and Knowledge Base. Dialogues Engine interfaces with the 
Rendering Engine in order to customize the dialogues to the specific type of 
communication and biometric devices used by the patient. RepUes to dialogues, 
and measurements from Biometric Devices are fed back into the Information 
Base. 



b. Care Management Engine The mdividual patient data resulting from the 
monitoring and management plan will be fed back into the Information Base, 
where it becomes a part of the patient record that is used in subsequent iterations 
of the Information and Knowledge Processing System to generate an increasingly 
individualized care plan with as the knowledge base grows and increases in its 
precision. This will allow the patient care plan to attain a greater degree of patient 
specificity and individualization with the passage of time, as the sj^tem has a 
better perspective of a patient's specific needs. As the research and development 
in this project refines the methodology and semantic network for sharing medical 
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knowledge, the feedback loop will be enhanced to enable a transition from 
personalized 'prepackaged programs' to truly patient specific 'individualized 
programs'. Care Management Engine may also interface with DSTs in order to 
provide gap reports, as shown in the figure below. 



DELIVERED CARE 



ELECTRONIC HEALTH RECORD 
LAB DATABASE 
CLAIMS DATABASE 
GENE DATABASE 
MISCELLANEOUS DATABASES 



STANDARD OF CARE 



KNOWLEDGE BASE 
PROTOCOLS^ 



CARE MANAGEMENT ENGINE 
DST * X COMPARES DELIVERED CARE 

AND STANDARD CARE 



I 



GAP REPORT GENERATED 



I 



SENT TO PHYSICIAN FOR REVIEW 



RESULT: 



STANDARDIZATION OF CARE 



Research Engine : The data aggregated from the original patient profile in 
combination with the longitudinal data created from the patient monitoring and 
management plan will be aggregated across the entire population of patients in the 
system. Such data will be blinded and no mdividually identifiable characteristics 
will be retained. The research engine tool set will enable a researcher to perform a 
query on a patient population and to identify subgroups of that population with 
different characteristics. With these clusters, the researcher will then be able to 
search for any other variable with meaningful correlation to the respective 
clusters. Examples of searches that will be performed include identifying 
subgroups of patients who respond differently to a pharmaceutical treatment 
regimen, and then to identify other characteristics that correlate with the sub 
grouping in outcomes. Examples include patient behavior, environmental 
variables, and gene variation. The goal is to enable academic research to identify 
characteristics that predict disease progression and complications so that 
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standards of care can be further individualized and the knowledge base will be 
continuously enhanced. 

One particularly interesting use of the research engine is specifically to correlate 
subgroups of patients based on treatment response and disease outcomes 
(phenotypic variables) to genetic variation. Many chronic diseases such as 
diabetes, hypertension, cardiovascular disease, obesity, and mental health 
disorders are thought to have a genetic component. The current effort uncovering 
single nucleotide polymorphism markers (SNPs), representing the common 
variations among the DNA of individuals, holds promise of understanding the 
genetic basis of chronic disease and related dmg response (pharmacogenomics). 
The problem, however, remains that complex disease may have multiple 
etiologies, and the interaction of multiple genes with behavioral and 
environmental factors may underlie chronic disease occurrence and progression. 
This project will assess the feasibility of conducting genetic epidemiological 
research using longitudinal patient data on phenotype and environment variables 
collected through patient monitoring and management plan in a population of 
patients. The goal will be to: (1) develop a program that monitors phenotype and 
environmental variables for a specific set of diseases; (2) work with a clinical site 
to collect daily data fi^om patients; (3) quantify phenotype and environment 
variability in sub-populations stratified by genetic factors; (4) develop linkages to 
life sciences projects capable of collecting and analyzing serum sample for 
genotyping; and (5) develop statistically appropriate design/analysis methods for 
assessing phenotype-genotype-enviromnent associations. 

m. Project Aims: 

RESEARCH AND DEVELOPMENT PHASE (0-24^^ month! 

• To develop a multi-dimensional model of disease and representative form 
of a patient's disease state; and to link the ongoing longitudinal 
monitoring to model, in terms of risk expression and aspects of care. 
Further, to structurally relate Knowledge Base and Information Base to the 
multi-dimensional model, which will enable the other objectives of the 
system. 

• To create the required content including patient queries and dialogues, and 
to categorize it by key aspects of patient care, in order to ensure a holistic 
approach towards patient care. 

• To develop a Dialogue Engine that will individualize medical 
management to the patient, and will allow the patient to be ubiquitously 
monitored, between clinical encounters, and in a manner that fits into 
his/her lifestyle. To link Dialogue Engine with Rendering Engine to 
ensure content presentation on an entire range of devices, and greater 
patient connectivity. 
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• To develop a Care Management Engine that automates content assigmnent 
on the basis of Infomiation Base of a patient and Knowledge Base of the 
disease. 

• To develop a Research Engine that peraiits researchers to identify 
subgroups and correlates of individuals with unique variables in their 
profile that set apart their condition firom the rest of the individuals; and to 
test hypotheses on this database of individuals. 

• To link remote care systems to Decision Support Tools, that will enable a 
paradigm shift firom current manual processes and methods of risk 
stratification to automated individuaUzed care; which will additionally 
optimize caregiver time, and enhance productivity. 

• To develop an open interoperability standard for all components of the 
system, including Knowledge base, Information base, Decision Support 
Tools (DST) and Rendering Engine. 

• To test the interoperability between Feedback Engine, Knowledge Base, 
Information Base, DST and Rendering Engine, and its compatibility other 
Integrated Project components, with currently used systems (including 
communication systems), and with external data systems, including legacy 
database systems. 



VALIDATION PHASE (25- 48^ months 



To apply the system m the management of chronic health diseases in a 
demonstration project in multiple centers across Europe, in a randomized 
control study 

To compare outcomes of disease managed by the system vis-a-vis that 
managed by present means, and aggregate data analysis for global impact. 
Outcomes analyses include health outcomes, cost-savings. 

To measure the impact the remote health management system has on 
certain key measures including: patient acceptability, satisfaction, 
utilization, clinical impact, medication compliance, quality of life, cost of 
care 

To conduct site specific data analysis by country, disease, and care model. 

To assess the feasibiUty of conducting genetic epidemiological research 
using longitudinal patient data on phenotype and environment variables 
collected through patient monitoring and management plan in a population 
ofpatients. 
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IV. State of the Art: 

Health Buddy and the iCare Desktop web service from Health Hero Network is a chronic 
care management solution that enables care providers to remotely monitor patients and 
detect problems early, while supportmg daily patient education and treatment 
compliance. The Health Buddy appliance was introduced 1999 in the US and in 2003 in 
Europe. Over thirty care provider sites are currently monitoring 2,500 chronic patients 
everyday, and over two million patient surveys have been taken to date. Sites where the 
disease management solution has been implemented include Veterans Health Affairs, 
Mercy Health System and Kaiser Permanente in the United States. Implementation is in 
process at University Louis Pasteur (ULP), Strasbourg, France as a part of post-transplant 
care management program, and 150 patients are expected to be enrolled in the program in 
2003. Additional implementations in process in Europe through agreements witii Abbey 
Healthcare Ltd (Ireland) and Sananet B.V. (Netherlands). 

Currently available programs include heart failure, coronary artery disease, diabetes, 
asthma, COPD, hypertension, and mental health, in addition to custom programs 
authored by care providers such as for post-transplant care and obesity. 

Current Technology 
The Technology 

The Health Hero platform consists of a series of web-based applications anchored by 
the Health Hero® iCare Desktop"* and a series of patient interfaces. The primary patient 
interface, the Health Hero Health Buddy®, is an easy-to-use inforination appliance placed 
in the patient's home. Health Hero provides other patient interfaces such as Health Buddy 
Web, for intemet-sawy patients, and are in development stages for patient interfeces 
based on mobile technologies and interactive television. The web applications and patient 
interfaces combine to form a secure infrastructure that links providers to their at-home 
patients while supporting a flexible, cost effective means for daily monitoring. 
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Figure I: The Technology Platform 



HEALTH HERO® TECHNOLOGY PLATFORM 




Health Hero iCare Desktop 

The Health Hero iCare Desktop application provides secure access to a series of web- 
based tools specifically designed for the patient management and workflow needs of a 
care provider. The iCaie Desktop's capabilities include analysis of patient responses and 
alerts, review of patient trend data, and production of patient reports. The key feature of 
the iCare Desktop experience is that it enables care providers to quickly review the status 
of a large population of patients, which is also what differentiates it from other standard 
clinical information systems. The review process makes it possible to identify the patients 
in need of attention or follow-up based on a set of subjective and objective data points 
giving a total view of the patient's daily health status. 

A care provider uses the iCare Desktop to view patient responses and identify 
responses within a patient population that are stratified as high, medium or low risk in the 
categories of symptoms, behaviors, and knowledge. This information is used to quickly 
assess which patients need an intervention on any given day. Care algorithms. Standard 
Operating Procedures (SOPs) and/or standing orders from the patient's physician guide 
the intervention. The Health Hero platform collects data that allows care providers to 
make clinical decisions based on longitudinal data, rather than a single telephone call or 
data point. 

The efficiencies of the Health Hero Platform are realized through the improved data 
collection capabihties of the Health Buddy appliance and through the workflow features 
of the iCare Desktop. Disease management programs with care managers using the 
Health Hero Platform have more than double the number of patients previously managed 
using a manual approach to disease management. 

Two specific features that greatly enhance workflow are the Inbox and the Patient 
Work List. These features provide two different views of patient results, allowing a care 
provider to deal with events as they happen using the Inbox, or in a more detailed manner 
withthe Work List. 

The Inbox feature of the iCare Desktop collects alerts, high risk and medium risk 
events in an interface similar to email software. As events are uploaded to the platform, 
the Inbox automatically creates a 'to-do" list of critical tasks for each care provider's 
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patient population. The items are classified by the standards of care and risk levels 
stipulated by the patient's care providers . 

The care provider is presented with a category and a subject for each Inbox event, 
describing the results. A typical care provider workflow would consist of scanning the 
Inbox for results, and either clicking on the date to review the detailed results data, or 
using the check box to mark that the patient results were reviewed. 

Figure 2: The Inbox 
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Whereas the Inbox collects a subset of patient results in a to-do list fashion, 
independent of the date and time, the Patient Work List is designed for review of a 
population m 24-hour time periods. This view provides the ability to quickly review the 
health of a population and determine which patients still require further assessment. 

The Patient Work List provides options for how the patient results are reviewed. A 
care provider is able to adjust both the time period of results and the disease programs of 
patients to displayed.. Supervisors and other iCare Desktop users with the correct 
permissions can also examine the Patient Work Lists of other care providers for quality 
control and "out of office" coverage. 

A conimon question asked by those responsible for the management of a large 
population of clm)nically ill patients is, "How do I know I served all the patients who 
needed care under my SOPs?" The Patient Work List addresses this problem in real-time 
through the use of a graphical indicator to display the review status of each result; 
As shown in Figure 3, each row of the Patient Work List includes a circular review 
indicator. A full circle indicates that the results have been reviewed by the care provider 
currently looking at the Work List. A half-filled circle mdicates that another member of 
the care team reviewed the result. An empty circle indicates that the result has not been 
reviewed. This "at-a-glance" interface allows care providers to quickly confirm that an 
SOP has been followed when appropriate. Full audit logs of the review and disclosure of 
patient results, includmg the reviewer name, time and date of review, and method of 
review are logged and maintained by the Health Hero platform. 
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Figure 3: The Patient Work List 
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Care providers have access to patient data collected over time through the trend chart 
pages, which are graphical representations of the patient data. Analysis aids, such as 
baselme weights and target goals, can be displayed on the trend charts to provide 
guidelines for review. 

Figure 4: iCare Trend Charts 
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Teams of care professionals provide the highest quality patient care and all members of 
the care team must be able to access clinical information for each patient in the maimer 
that is the least disruptive to their existing workflow. The iCare Desktop provides robust 
reporting tools that facilitate the faxing, emailing, and printing of reports for review 
outside of the iCare Desktop \yorkflow. 

For those members of the care team who choose to use the web-based tools for patient 
management, the iCare Desktop is designed with role-based permissions, so each 
individual contributor to the patient's care is able only to interact with the specific patient 
data that is required to complete their professional function. 

Provideis access the iCare Desktop &om a personal computer with an Internet 
connection. The iCare Desktop requires no installation of software or hardware, and 
little-to-no staff support from provider Information Technology (IT) groups. System 
maintenance, backup, and security is managed by Health Hero Network and it's 
networking partners. 

Health BuddV* Appliance 

The Health Buddy appliance, shown in Figure 5, serves as the primary patient 
interface for secure communication between patients and ttie network. The Healtii Buddy 
was designed as an easy-to-use communication appliance for placement in the patient's 
home, and has gone through significant commercial vaUdation as a welcome in-home 
healthcare tool. 

The ease of use begins with the Health Buddy installation process, which is most 
often conducted by the patient with no assistance. The Health Buddy reqvdres a standard 
telephone outlet and standard power outlet, and requires no additional telephone lines, 
software, or computer experience. When power is applied, the Health Buddy presents the 
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patient with an interactive Health Buddy tutorial, and then within one hour of taking the 
tutorial, the patient receives their first Health Buddy survey. 

The Health Buddy provides the patient with at least one survey per day. The surveys 
are designed to enable patients to easily respond to a range of questions, that relate to 
important aspects of care for their specific condition. Once the patient answers the 
questions in the survey, the Health Buddy stores and transmits the information back to 
the care providers, who will review the data using the iCare Desktop. Although the 
standard model of care for patients uses a once-per-day survey transmission mode, tiie 
transmission of results can be customized to upload patient data at any desired fi^quency, 
including in response to a particular patient result. 

Figure 5: The Health Buddy 




The Health Buddy is intended to gather quantitative and qualitative patient 
information tiirough a simple question, answer and education session. In some cases, it 
is important to augment quantitative and self-reported qualitative data with information 
collected directly fi-om medical devices. The Health Buddy appliance, through the 
Buddylink™ feature, allows the collection of data fi-om medical devices, such as blood 
glucose meters, weight scales, and blood pressure cufife. The objective data is collected 
during the survey process so that the patient still benefits fix>m the education, behavior 
modification, and personalized responses. 

The benefits of employing the Health Buddy and the iCare Desktop web service in 
disease management have been validated in articles published in several peer-reviewed 
joumals. Briefly, the Health Hero Disease Management Programs have shown clear 
benefits over other programs, in terms of- 

Cost Benefits: Health Buddy reduces hospital admissions and costs by detecting 
problems before they become a crisis. A recent study at the Veterans Health Affairs 
reported a 60% reduction in hospital bed days of care in a one year trial with 791 CHF, 
COPD, diabetes, and hypertension patients in a chronic care program in which most 
patients were monitored daily using Health Buddy. Similar cost savings were reported in 
Medicare HMO patients. (Meyer et al. Disease Management 2002; 5: 87-94. Vacaiio et 
al. Disease Management 2001; 4(3): 1-10.) 
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Access to Care : Health Buddy increases access to care by expanding the capacity of care 
providers to monitor patients using existing resources. Through daily communication, 
patients are able to access timely care before conditions become a crisis. At Mercy Health 
System, a part-time nurse provides daily monitoring for 425 heart failure, diabetes, and 
hypertension patients. With telephone-based monitoring only, a full-time nurse could 
provide weekly monitoring to less than 100 patients. The efficiency achieved through 
Health Buddy allowed for coverage of uninsured patients who otherwise would have 
received no care at all (Cherry et al. Diabetes Technology & Therapeutics; 4(6): 793- 
791.) 

Quality of Care : Health Buddy improves quality of care by providing timely, relevant, 
and actionable information to healthcare providers so that care can be coordinated in a 
quality assured process. Care providers are able to detect complications before they 
become acute and result in hospital admissions, providing quality care that reduces 
painful and costly complications by maintaining patients in a healthier state. Health 
Buddy also improves patient outcomes by improving treatment compliance through 
educating, motivating and monitoring patients daily, (Cherry et al, Lippincott's Case 
Management 2000: 5(5): 191-198. Guendehnan et al. Archives of Pediatric and 
Adolescent Medicine 2002: 156: 114-120.) 



V. Scope for Innovation- 





State of the Art 


Scope for Innovation 


Patient Dialogue 
Engine 


Pre-packaged, mass 
customized programs 


Automated individualization of 
programs 


Content libraries 


Content generated by knowledge base 
rales applied to information base 


Health Buddy 


Interface to Rendering Engine for any 
device 


Care Management 
Engine 


Risk stratification 


Intelligent risk tuning and link to DST 


Organizational workflow 
and efficiency tools 


Organizational optimization 


Manual feedback process 


Automated feedbax:k loop 


Research Engine 


Data Export to S AS 


Identify subgroups and correlations 




Test hypotheses on living database 


Table: The contribution of Feedbacks 


Engine in terms of innovation 
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VI. Multi-Dimensional Model of Disease 
The 3-DimensionaI Model of Disease- 
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RISK 



INTERVENTION 

(*) (4) 
I— RISK — * 



HiGm 

RISK 



PROTOCOL 




Z-AXIS 
RISK EXPRESSION 



X-AXIS 



RISK SCALE 



A 3'dimensional model of disease. 

The above diagram illustrates a three dimensional model of disease. In this model, a 
patient's health at a point in time is determined on a relative risk scale. The Y-axis 
contains slabs, each relating to a specific aspect of care. For instance, in a multi-system 
disease like Diabetes, one slab relates to blood glucose control, another to the 
cardiovascular system, still others to foot care, the neurological, renal and ophthahnic 
systems. Given the complex multiple interactions between different aspects of care, there 
may be occasional overlap between different slabs. For instance, glucose control, when 
appUed in the long-term sense, is related to the cardiovascular, renal and most other 
systems. In such cases, each factor of interest is represented separately and independently 
on the Y-axis. 

Each aspect of care m the individual patient is further modulated by a patient's 
knowledge of disease (in that aspect of care), patient behavior, signs, symptoms, test 
results, and general resistance to medical advice. Each such aspect of risk expression is 
represented in the model on the Z-axis. A specific aspect of care (Y) for a specific 
expression of risk (Z) is termed a ^health context*. The X-axis relates to the relative level 
of risk exhibited by an individual patient for each health context. Lower x values of a 
patient indicate a better state of health. 



For example, in case of blood glucose control m diabetes, the actual behavior of the 
patient, and disease outcomes are a function of the 
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1 . Patient's knowledge- a patient with a greater knowledge (lower risk) of the long- 
term complications of (diabetes, and its relationship to blood glucose control is 
more likely to be compliant with the diabetic diet and regimen (better outcome). 

2. Behavior- Humans exhibit varying behaviors regardless of the level of knowledge 
of their disease condition. Some individuals are more health conscious (lower 
risk) than the others. 

3. Signs, Symptoms, and test results-. A patient whose blood glucose values are 
consistently within the normal range (lower risk) gets the requisite positive 
feedback, encouragement, and impetus to further adhere to the prescribed medical 
regimen. Conversely, patients who develops complications of medication, such as 
nausea, vomiting or hypoglycemic attacks are at a greater risk of being non- 
compliant with medical advise. 

4. Follow-up, compliance, and Resistance- On continued follow-up, one or more of 
the above factors may change. For instance, as a patient's knowledge of his/her 
disease condition increases, he/she may be more inclined to be compliant with the 
medical regimen. Resistance is defined as the tendency of patients to resist 
medical care and the changes it entails with regard to one's lifestyle and habits, hi 
the context of the disease model, resistance is additionally related to a patient's 
perception of the value of medical regimens. 

The Fourth Dimension: Time- The three dimensional model is *static', in that it 
doesn't describe the changes that take place in the patient's disease state with time, 
nor is it descriptive about the effects of various interventions and medical therapies 
on the Information Base. To this end, the fourth dimension of time is added to tiie 
three-dimensional model. The aim of disease management is to achieve the lowest 
overall risk in a group of patients. 




To-O Ti-t T2-Ti*t T3-T2*t 



TIMEfT) ► 

It permits outcomes analysis to be performed. Additionally, it allows one to study (and 
test) effects of multiple expressions of risk and aspects of care with regard to one another, 
as a function of time, in a single patient. 

Description of System Components in relation to the Multi-Dimensional ModeL 
Knowledge sources and medical literature typically supply recommendations as to 
'standard of care' in the form of care management algorithms. However, these algoriiOmis 
would need to be interpreted and applied into the system by Decision Support Tools and 
Care Management Engine, Further, the format and logjc would need to be common for all 
the system sub-components, in order that interfacing is made possible by the use of 
AppUcation Program Interfaces. Finally, the logic has to be mapped to die multi- 



18 



dimensional model of disease. The proposed system architecture, type, nature, and format 
of data exchange between the system's components will be better understood when 
explamed in reference to standard care management algorithms. One such algorithm, 
specifically an algorithm relating to the management of patients with congestive heart 
failure by Care Managers is given in the table below- 



TITLE: 
POLICY: 



CONGESTIVE HEART FAILURE SURVEILLANCE DIURETIC ALGORITHM 

1. Function: 



To outline the nursing management of patients who are referred by their physician to 
Health Buddy Congestive Heart Failure Program. Registered nurses independently 
titrate the patient's regularly prescribed diuretics and potassium based on the patient's 
symptoms and weight gain using an approved algorithm. 
Circumstances under which the RN may perform this function: 
Registered nurses who work in Health Buddy Congestive Heart Failure Disease 
Management Program may initiate this standardized procedure when directed by the 
patient's physician. 

Patient contraindications to use of this standardized procedure include pulmonary 
edema, new or refractory chest pain, new or sustained arrhythmia, syncope. 



PROTOCOL: 



2. 



Definition - The Health Buddy Congestive Heart Failure Disease Management 
Program is an outpatient-based approach to managing chronic CHF patients, where 
Registered Nurses provide education, support, and clinical fbllow-up to patients with 
congestive heart feiture under the direction of a Physician. 

Assessment - . 
failure 



- Assess patient for signs and symptoms of worsening congestive heart 



Breathlessness, paroxysmal nocturnal dyspnea, orthopnea, dyspnea at rest 

Weight gain 

Edema 

Compliance with medication regime 



PROCEDURAL STEPS 




1 . Once a change in status has been indicated, 
inten/iew patient via telephone to verify the patient's 
status. 

2. Interview patient to determine subjective complaints 
of SOB. fatigue, and other signs & symptoms of 
CHF. 

3. Based on the patients subjective symptoms and 
cunrent weight, implement the following. 


Total dally doses of diuretics should not exceed the 
following limits unless approved by physician: Lasix 
240 mg, Bumex 10 mg, Metolazone 5 mg. Demadex 
240 mg. 


Patienfs Symptoms 


Weight 
Gain in 
Pounds 


Treatment 
Category 


Treatment Legend 


No new symptoms 


1-2 


Restrict salt 


1= Extra dose of the patient's regularly prescribed 
diuretic and potassium now*. 

2 = Extra dose of the patient's regulariy prescribed 
diuretic and potassium now, then an extra daily dose 
for 3 days.* Daily phone calls from Health Buddy 
nuree. Obtain renal panel within 48 houre if current 
creatinine >1. 8. 

3 = Double dose of the patienfs regulariy prescribed 
diuretic and potassium now, then an extra daily dose 
for 3 days.* Health Buddy nurse will notHy patienfs 
primary physician. Obtain renal panel within 48 hours If 




3-4 


1 




>4 


2 


New or worsening 
paroxysmal noctumal 

dyspnea 


1-2 


1 




3-4 


3 




>4 


3 


Orthopnea 


1-2 


2 




3-4 


3 




>4 


3 


Shortness of breath when 
seated 


1-2 


2 
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3-4 


3 


cunrent creatinine >1 .8. 

4 = Double dose of tiie patient's regularly prescribed 
diuretic and potassium now and again in 4 hours.* 
Healtii Buddy nurse will notify patient's primary 
physician; office visit scheduled. Obtain renal panel (if 
cun-ent creatinine >1,8) and Mg++ wittiin 48 hours. 

5 = Refer to emergency departinent Healtii Buddy 
nurse will notify physician and appropriate emergency 
department 




>4 


4 


Pulmonary edema 
refractory to treatment 
category 4, chest pain 
(new or refractory to nitro). 
arrhythmia (new or 
sustained), syncope 




5 


4. To manage the patient who loses weight below their 
pre-detennined dry weight: 

2-3 pound weight loss- halve diuretic for one day; if 
recun^nt, reduce to half dose every otiier day.* 

4-6 pound weight loss - reduce diuretic to half dose 
daily, obtain renal paner, and notify physician. 
7 or more pounds - hold diuretics, obtain 
renal paner, and notify physician. 


*Essential to reduce potassium supplements an 
equivalent amount 


5. To manage tiie patient with excessively rapid weight 
loss: 

3-5 pounds in 24 hours** - confirm appropriate 
potassium replacement 

Weight loss of more ttian 5 pounds in 24 hours** - 
confinn appropriate potassium replacement, obtain 
renal panel, and notify physician. 


** If weight loss continues longer than 24 hours, obtain 
renal panel land notify physician. 


7. Follow-up phone calls from Health Buddy nurses are 
required for treatment categories 2, 3, 4, and 5 and 
for all patients with weight loss below dry weight and 
excessively rapid weight loss within 72 hours of 
initiatina the treatment change. 


The primary physician must be consulted if tiie patient 
meets criteria for emergency department referral, 
weight loss below dry weight of 4 or more pounds, and 
excessively rapid weight loss of more than 5 pounds in 
24 hours. 



Table: A health context management algorithm 



Knowledge Base : Knowledge Base, the summation of medical knowledge and concepts 
is organized by location pointers, expressions that define the location of any aspect of 
disease on the multi-dimensional model, and protocols, which are logical expressions that 
define the relationships between the hedth contexts, and the actions that need to be taken 
for possible combination of factors within the health context. Within the multi- 
dimensional model of disease, location pointers are represented on the X, Y- and Z-axis. 
Every possible piece of information that is collected by the system is mapped on to the 3- 
dimensional model 
In the above example, 



DIRECTIONAL POINTER: CHF SURVEILLANCE 


DISEASE: 


CONGESTIVE HEART FAILURE 


ASPECT OF 
CARE: 


DIURETIC MANAGEMENT 


KNOWLEDGE : 


OF ORTHOPNEA YES NO | 
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OF 

PAROXYSMAL 

NOCTURNAL 

DYSPNEA 


YES 


NO 




OF NECESSITY 
TO RESTRICT 
SALT 


YES 


iHKJ 




BEHAVIOR: 


EXERCISING 
REGULARLY 


YES 


NO 


OCCASIONALLY 


RESPONDS TO 
HEALTH BUDDY 


YES 

X AO 




r^OOa e TOMTIT T V 


RESPONDS TO 
PHONE CALLS 


YES 


NO 


OCCASIONALLY 


SIGNS : 










SYMPTOMS : 




MO MRW 

SYMPTOMS 


"NTCW OP 
PND 




TEST 
RESULTS : 


WEIGHT GAIN 


1-2 LB 


3-4 LB 


>4 LB 


CREATININE 


< VALUE > 






WEIGHT 








K+ LEVEL 


<VALUE> 








WITH 

MEDICATION 






POOR 


COMPLIANCE 
WITH DIET 


GOOD 


MODERATE 


POOR 


FOLLOW UP: 











Thus, Knowledge Base defines the location of the particular attribute on the model. It is 
common to all patients with a single disease. Further, the *risk-states' that are given to a 
particular variable is defined at the time of creation of the model. For example, in the 
health context of Behavior (Responds to phone calls), a value of 'Yes' will lie towards 
the low risk end of the X-axis, while, a value of *No' will lie towards the high risk end. 
For continuous variables, for example, the results of a laboratory test, or Creatinine 
values, the value of a health context is represented as such, on a scale. In case where a 
low value is medically significant, such as a low serum potassiiun value, it is represented 
by two contexts, one for hypokalemia (low potassium) and another for hyperkalemia 
(high potassium values). On the contrary, if low values of a measurement have no 
medical significance, for example Creatinine value, then it is represented by a single 
context. 

In order to automate patient care, and to achieve the other objectives of the system, it is 
necessary to incorporate into the system, the logic that will enable it to decide on a course 
of action to be taken, or a treatment plan, which are the Protocols. Protocols tell the 
system the action that needs to be taken for any of a combination of unique variables in 
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the Information Base. Protocols are the 'threads' or connections that Hnk the discrete data 
components ^t ultimately forms the Information Base. 
In the above context, 

PROTOCOL: DIURETIC PRESCRIPTION 
IF SYMPTOMS= 'NO NEW SYMPTOMS' 
AND WEIGHT GAIN = '1-2' 

THEN ACTION: RESTRICT SALT 

IF SYMPTOMS= 'NO NEW SYMPTOMS' ~ 

AND WEIGHT GAIN = '3-4' 

THEN ACTIONl: INCREASE_DOSE_DIURETIC 

THEN ACTI0N2: GIVE PATIENT POTASSIUM 

IF SYMPTOMS= 'NO NEW SYMPTOMS' 

AND WEIGHT GAIN = '>4' 

THEN ACTIONl: INCREASE_DOSE_DIURETIC 

THEN ACTI0N2: GIVE PATIENT POTASSIUM FOR 3 DAYS 

THEN ACTIONS : ALERT CARE MANAGER: TO PHONE PATIENT 

THEN ACTI0N4: OBTAIN RENAL PANEL 



hiformation Base- This is individual to a patient, and is created in response to the data 
(responses to queries), measurements of tiie patient, and external data sources. In the 3 
dimensional model of disease, a new 3-dimensional model is created for each new piece 
of information. In general, the information base provides a health profile of the individual 
at that point of time, and is sufficient for deciding the care management, when used in 
reference to Knowledge Base. The table below depicts the Information Base of a 
particular patient at a point in time. 



PATIENT NAME: SCOTT, JANE 


DISEASE: 


CONGESTIVE HEART FAILURE . 


DATE, TIME 


9 APRIL 2003, 1400 HRS, GMT 


KNOmjEDGE: 


OF ORTHOPNEA 




NO 




OF 

PAROXYSMAL 

NOCTURNAL 

DYSPNEA 


YES 






OF NECESSITY 
TO RESTRICT 
SALT 


YES 






BEHAVIOR: 


EXERCISING 
REGULARLY 






OCCASIONALLY 


RESPONDS TO 
HEALTH BUDDY 


YES 






RESPONDS TO 
PHONE CALLS 






OCCASIONALLY 


SYMPTOMS: 




NO NEW 
SYMPTOMS 


NEW OR 
WORSENING 


ORTHOPNEA 
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PND 




TEST 
RESULTS : 


WEIGHT GAIN 




3-4 LB 




CREATININE 


1.7 






WEIGHT 


149 LB 






K+ LEVEL 


4.4 






COMPLIANCE : 


COMPLIANCE 
WITH 

MEDICATION 


GOOD 






COMPLIANCE 
WITH DIET 




MODERATE 





However, in some cases, current Information Base alone is insufficient in deciding the 
course of management of the patient. Previous or baseline values are required for 
comparison. This is especially the case where the laboratory values are used. For 
example, in this patient with Congestive Heart Failure, a weight of 65 kg, has no meaning 
in itself, unless it is compared with the patient's previous weight. A weight gain could be 
the first sign of fluid accumulation and impending heart failure. 

Serial follow-up of Information Base has immense Research utility, for example in 
outcomes analysis, and in correlating the effects of a new drug or intervention on an 
entire range of patient variables. 

Decision Support Tools - Decision Support Tools determine the extent to which provided 
care is consistent with the consensus standard of care. For example, in Diabetes, 
knowledge base protocols will require that the patient has a HbAlc test every three 
months. The following protocol logical expression is ^plied to determine if the standard 
of care has been followed. 

PROTOCOL 

IF [DATE (TODAY) ] - [DATE (HBAIC-TEST) ] > 90 , 
THEN 

DOACTION; INFORM CARE MANAGER (PATIENT) 

The following protocol 'tells' the Decision Support Tools the effects that a particular 
intervention has on the risk factor levels of different health contexts. On increasing the 
daily injected insulin dose, the risk of developing hypoglycemic episodes is raised 
significantly, also there is a risk of weight gain and an increased cost of medication to the 
provider. Finally, the biometric device is scheduled to receive three blood glucose 
samples for a week. 



IF INTERVENTION (INCREASE_INSULIN_DOSE)= ^TRUE^ 
THEN RISK(HYPOGLYCEMIC_EPISODE) = RISK + (VA Rl) 
ALSOTHEN RISK(WEIGHT_GAIN_NEAR_TERM) RISK -h (VAR2) 
ALSOTHEN (MEDICATION_COST) = (MEDICATION_COST) + ( VAR3 ) 
ALSOTHEN DO (TEST_GLUCOSE_VALUE) = 3TIMES/DAY * 1 WEEK 
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In deciding the course of management of the patient's condition, DSTs reference the 
Information Base and the Knowledge Base. 



VII. Feedback Loops- 

The Feedback Engine will enable a regular and ongoing interaction between the patient 
and the care manager, physician and researcher, outside of the clinical encounter. 
There will be three main types of feedback loops- the Information Feedback Loop, the 
DST Feedback Loop, and the Research Feedback Loop. 

The Information Feedback Loop- The Information Feedback Loop provides feedback 
to the Information Base. It is the feedback loop from the perspective of a patient, 
enabling individualized communication, and ubiquitous monitoring of a patient. Updates 
to the patient Information Base are made automatically, and in real time, thus allowing 
for reduced latency from the provision of information to action taken. Dialogues are not 
only customized to comprehensive and updated infomiation, but also are rendered for 
output in a variety of formats. 
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In the fiurst step, Dialogue Engine links to Knowledge Base and Information Base in 
order to create and select dialogues that are most suited to the patient's Knowledge 
Base and Information Base. In the next step, Dialogue Engine interfaces with 
Rendering Engine to format the dialogues for transmission and uptake by the patient 
communication device and biometric device. Query Dialogues are sent to the 
Communication Device, for display to the patient. Additionally, Dialogues are sent to 
Biometric Device, either directly, or via communication device with commands to 
collect measurements of physiological variables. Replies of the patient and 
measurements from biometric devices are re-routed to the Dialogue Engine throu^ 
the same communication system. The Dialogue Engine fiirther interfaces with 
Rendering Engine, in order to interpret the signals, and appends the newly collected 
data to the Information Base. The updated Information Base is in tum used in 
subsequoit iterations of the patient management process. 
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DST Feedback Loop- The DST Feedback loop provides feedback to Decision 
Support Tools, and its updating in real time, resulting in care that is provided on the 
basis of patient data that is updated in real time. 

EHR LAB DATABASE CLAIMS DATABASE GENEDB MISC.DB 
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In the first step, the Care Management Engine interfaces with hiformation Base, 
Knowledge Base, and DSTs to create Dialogues and Interventions suited to the 
patient's disease condition. These dialogues and interventions are rendered to the 
format of communication by rendering engine. Patient replies to query dialogues, 
Biometric test results, and updates of Laboratory and EHRs are fed back into the 
Information Base. The feedback provided from the received data is used to create 
better Decision Support Tools that enable better automated processing of patient care. 
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Research Feedback Loop- 
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Research Feedback Loop is primarily used by a researcher to make new discoveries and 
to test hypotheses on the system. Information Base is organized in the form of a neural 
network, thus enabling the Research Engine to scan the data, and to look for correlates in 
the data, or events that have a greater correlation than can be explained by chance alone. 
These correlates are forwarded to the Researcher, who will form a hypothesis. In order to 
test the hypothesis, the Researcher may use Research Engine to interface with Dialogue 
Engine, and use it to create Dialogues and requests for measurements from Biometric 
Device. The results of the queries and tests measurements are forwarded to Infomiation 
Base, and thence to the Researcher. Further statistical analyses may be performed, and 
associations may be elicited. For example, the researcher may be able to prove the 
existence of an unknown factor in a chronic disease that causes different people to 
respond differently to medication. Furflier correlation with molecular and genetic studies 
may be done to prove or refute the hypothesis. 
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